Determining landmark detectability

ABSTRACT

In some examples, a system may receive location information. The system may determine at least one landmark based on the location information. In addition, the system may determine one or more current conditions for the at least one landmark. Further, the system may receive sensor configuration information. Based on the sensor configuration information and the one or more current conditions, the system may determine the detectability of the at least one landmark.

BACKGROUND

Advanced driver assistance systems (ADAS) and semi-autonomous vehiclesystems, self-driving systems, or otherwise autonomous driving (AD)systems are systems that automate or otherwise enhance vehicle controlfor improved safety, automated navigation, and the like. Conventionalnavigation systems in traditional vehicles may typically provide one ormore routing options for traveling from a source location to adestination location. Examples of factors considered by conventionalnavigation systems when determining routing options may include time todestination, traffic conditions, whether tolls are required, and thelike. However, in the case of vehicles equipped with modern ADAS and ADsystems, determining navigation routes using just these factors may notbe sufficient for ensuring occupant safety and/or correct vehiclenavigation.

SUMMARY

In some implementations, a system may receive location information. Thesystem may determine at least one landmark based on the locationinformation. In addition, the system may determine one or more currentconditions for the at least one landmark. Further, the system mayreceive sensor configuration information. Based on the sensorconfiguration information and the one or more current conditions, thesystem may determine the detectability of the at least one landmark.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is set forth with reference to the accompanyingfigures. In the figures, the left-most digit(s) of a reference numberidentifies the figure in which the reference number first appears. Theuse of the same reference numbers in different figures indicates similaror identical items or features.

FIG. 1 illustrates an example landmark detection and vehicle navigationsystem according to some implementations.

FIG. 2 is a flow diagram illustrating an example process for determiningan optimal route according to some implementations.

FIG. 3 illustrates an example of determining multiple feasible roadsegments according to some implementations.

FIG. 4 is a flow diagram illustrating an example process for determininga safety score according to some implementations.

FIG. 5 is a flow diagram illustrating an example process for determininga predicted route according to some implementations.

FIG. 6 is a flow diagram illustrating an example process for determininglandmark data for localization according to some implementations.

FIGS. 7A and 7B illustrate examples of landmark shape extractionaccording to some implementations.

FIG. 8 is a flow diagram illustrating an example process for performinglocalization according to some implementations.

FIG. 9 illustrates an example of sensing landmarks using active sensorscorresponding to where the landmarks are expected to be according tosome implementations.

FIG. 10 is a flow diagram illustrating an example process for updatingthe landmark database according to some implementations.

FIG. 11 illustrates an example data structure of landmark informationstored in the landmark database according to some implementations.

FIG. 12 illustrates an example data structure of landmark informationstored in the landmark database according to some implementations.

FIG. 13 illustrates an example data structure of landmark informationstored in the landmark database according to some implementations.

FIG. 14 illustrates an example data structure of landmark informationstored in the landmark database according to some implementations.

DESCRIPTION

Some implementations herein are directed to techniques and arrangementsfor selecting landmarks available in a navigation map by taking intoconsideration various factors such as weather conditions, time of day,traffic conditions, lighting conditions, the sensor configuration on thespecific vehicle, and so forth, when determining the usability of theavailable landmarks. For instance, if the landmarks are usable, thevehicle is predicted to be able to localize itself on a correspondingmap, thereby providing safer and more accurate navigation. On the otherhand, if the landmarks on at least a portion of a candidate route aredetermined to not be currently useable, the candidate route might not beselected.

Some examples herein employ landmark-based localization in ADAS and ADapplications to localize a vehicle position with respect to a map, suchas high definition (HD) map. An HD map may provide extremely highprecision to enable an autonomous vehicle to maneuver itself within a 3Dspace. One technique employed herein for enabling the vehicle to locateitself with respect to the map (localization) is for the vehicle todetermine its location with respect to the real world positions ofvarious landmarks identified on the HD map. For example, the predictedquality and effectiveness of localization may be based at least in parton the landmarks available along each of a plurality of possible routesthat may be navigated.

There are various types of landmarks such as buildings, road curbs, lanemarkers, trees, poles, traffic signs, etc., that may be included on anHD map. Some implementations herein may determine the detectability ofthese landmarks based on considerations such as sensor type or qualityon the vehicle, as well as current external factors such as weatherconditions, time of day, lighting conditions, and so forth. If thelandmarks are detected correctly, they can be effectively matched withcorresponding landmarks on the HD map to localize the vehicle withrespect to the HD map. Accordingly, some implementations herein maydetermine in advance which landmarks can be detected effectivelyconsidering the external factors mentioned above and considering thesensor configuration of the vehicle.

The system herein may include a vehicle navigation human-machineinterface (HMI) located on the vehicle for enabling a human to interactwith the navigation framework herein. The system may further include aglobal landmark database stored at an network storage location, such asat a service computing device 108 or the like. In addition, the systemmay include one or more machine learning models (MLMs) or other types ofalgorithms for determining a safety score prediction for determining thepredicted safety of possible navigation routes. Further, the system mayinclude one or more MLMs or other types of algorithms for determininglocalization. In some examples, the localization MLM(s) or otheralgorithm(s), and the safety score MLM(s) or other algorithm(s), may beexecuted on a service computing device remote from the vehicle, and thecorresponding information may be provided to the vehicle prior to orduring vehicle navigation.

Further, the system may include one or more MLMs or other type ofalgorithms for performing route selection. In some cases, the routeselection MLM(s) or other algorithm(s) may be executed on an autonomousdriving (AD) electronic control unit (ECU) or other computing device onboard the vehicle. In addition, a vehicle ECU or other computing deviceon board the vehicle may execute a localization program for determininga location of the vehicle with respect to the HD map based onidentifying landmarks from the map. Additionally, the system may includea landmark update MLM or other algorithm for updating the landmarkdatabase following completion of a navigated trip. In some examples, thelandmark update MLM or other algorithm may be executed on a servicecomputing device remote from the vehicle.

Some examples herein include navigation techniques for ADAS and/or ADsystems. Further, some examples include a method and/or system to selectlandmarks for routing and localization by taking into considerationvarious current different local conditions to provide improved safety tovehicle occupants. For instance, the routing and localization employedherein may enable a determination of vehicle controllability whenoperating in an autonomous mode prior to starting a trip. For example,by localizing itself accurately within a map, the vehicle is able tonavigate through the map seamlessly. Implementations herein providetechniques for improving localization quality and effectiveness fordetermining whether a vehicle will be able to traverse a proposed routesafely and correctly. Thus, the predicted localization accuracy hereinmay take into account various factors such as type, location and fieldof view of the sensors used on the vehicle, as well as weatherconditions (e.g., rain, snow, fog), visibility (such as day vs night),and so forth.

Determining the localization accuracy in advance enables the vehiclecomputing device to evaluate the vehicle capability to drive on a givenroute autonomously for a plurality of possible routes. To ensure safetyof an autonomous vehicle and its occupants, the localization accuracymay be very high, e.g., within tens of centimeters. The localizationaccuracy may rely at least in part on sensor capabilities for detectinglandmarks and matching the detected landmarks with the map landmarks onthe HD map or other map being used for navigation. Consequently,implementations herein may achieve this level of accuracy by selectinglandmarks that are predicted to provide superior results forlocalization.

A route selection program executed by the vehicle computing device maydetermine whether the destination has been provided by a user at thestart of every trip. If the destination has not been provided, the routeselection program may predict the destination, such as by using adestination prediction MLM and/or based on information received via avoice communication interface or other HMI. After the destination hasbeen determined, possible routes from the source location to thedestination location may be determined and divided into road segments.For instance, multiple feasible segments from the source location may bedetermined and external information may be received for each segment,e.g., from a Web server any of various other information sourcecomputing devices available over a network.

Examples of external information that may be received may includeweather conditions, time of day, traffic conditions, lightingconditions, local events taking place, etc. The current sensorconfiguration of the vehicle may also be received, e.g., from a vehicleECU, vehicle storage location, or the like. A localization programexecuted by the vehicle computing device may determine landmarks fromthe landmark database located at the network location, and may determinea respective weight for each landmark along each route segment based atleast on the factors mentioned above. The respective weight for thelandmark along each road segment may then be used to determine thequality or effectiveness of localization along the road segment. Thisprocess may be performed iteratively until all road segments aredetermined for the designated destination.

A safety score may be determined for each feasible route based on thedetermined road segment scores. In some examples, the safety score maybe used for route selection in conjunction with various otherconsiderations such as time, cost, efficiency, and the like, for allfeasible routes. The route selection program may be executed todetermine which landmarks to use for localization, and may select one ofthe routes as being the optimal route. At the end of each trip thelandmark database may be updated with newly detected landmarks and/orlandmarks detected in varied local conditions, such as weather, time,lighting, etc.

For discussion purposes, some example implementations are described inthe environment of selecting and navigating a travel path for a vehiclebased on available sensors and local conditions. However,implementations herein are not limited to the particular examplesprovided, and may be extended to other types of sensing devices, othertypes of vehicles, other types of local conditions, other types oflandmarks, and so forth, as will be apparent to those of skill in theart in light of the disclosure herein. For example, the solution hereinis scalable, and may be applied to ubiquitous systems in addition toground vehicles, such as in the case of the mining industry for heavymining trucks, marine industry for ships, agricultural industry foragriculture equipment, and so forth. Implementations herein may also bescaled to smaller applications, such as logistic robots and/orautonomous bikes, such as within geo-fenced areas with fewer parameters.

FIG. 1 illustrates an example landmark detection and vehicle navigationsystem 100 according to some implementations. The system 100 includes avehicle 102 having one or more vehicle computing devices 104 able tocommunicate over one or more networks 106 with one or more servicecomputing devices 108. In addition, the service computing device(s) 108,and in some cases, the vehicle computing device(s) 104 may be able tocommunicate over the one or more networks 106 with one or moreinformation source computing devices 110, such as web servers, serviceproviders, public databases, private databases, or the like. The vehicle102 may further include one or more sensors 112 and one or more vehiclesystems 114 that are in communication with the vehicle computingdevice(s) 104, such as via a CAN bus (controller area network bus) (notshown in FIG. 1 ) or the like.

Each vehicle computing device 104 may include one or more processors116, one or more computer-readable media 118, one or more communicationinterfaces (I/Fs) 120, and one or more vehicle human-machine interfaces(HMIs) 122. In some examples, the vehicle computing device(s) 104 mayinclude one or more ECUs (electronic control units) or any of variousother types of computing devices. For instance, the computing device(s)104 may include one or more ADAS/AD ECUs for controlling at least someof the vehicle systems 114, such as to perform ADAS and/or AD tasks,such as navigation, braking, steering, acceleration, deceleration, andso forth. The computing device(s) 104 may also include one or more otherECUs, such as for controlling other systems of the vehicle systems 114.

“ECU” is a generic term for any embedded processing system that controlsone or more of the systems, subsystems, or components in a vehicle.Software, such as a vehicle control program 124, a route selectionprogram 126, and a localization program 128 may be executed by one ormore ECUs and may be stored in a portion of the computer-readable media118 (e.g., program ROM, solid state storage, etc., as discussed below)associated with the respective ECU to enable the ECU to operate as anembedded system. ECUs may typically communicate with each other over avehicle bus, such as the CAN bus mentioned above, according to a vehiclebus protocol. As an example, the CAN bus protocol is a vehicle busprotocol that allows ECUs and the vehicle systems 114 to communicatewith each other without a host computer. CAN bus may include at leasttwo different types. For example, high-speed CAN may be used inapplications where the bus runs from one end of the environment to theother, while fault-tolerant CAN is often used where groups of nodes areconnected together.

Each ECU or other vehicle computing device 104 may include one or moreprocessors 116, which may include one or more of central processingunits (CPUs), graphics processing units (GPUs), microprocessors,microcomputers, microcontrollers, digital signal processors, statemachines, logic circuits, and/or any devices that manipulate signalsbased on operational instructions. As one example, the processor(s) 116may include one or more hardware processors and/or logic circuits of anysuitable type specifically programmed or configured to execute thealgorithms and other processes described herein. The processor(s) 116may be configured to fetch and execute computer-readable instructionsstored in the computer-readable media 118, which may program theprocessor(s) 116 to perform the functions described herein.

The computer-readable media 118 may include volatile and nonvolatilememory and/or removable and non-removable media implemented in any typeof technology for storage of information, such as computer-readableinstructions, data structures, programs, program modules, and other codeor data. For example, the computer-readable media 118 may include, butis not limited to, RAM, ROM, EEPROM, flash memory or other memorytechnology, optical storage, solid state storage, magnetic disk, cloudstorage, or any other medium that can be used to store the desiredinformation and that can be accessed by a computing device. Depending onthe configuration of the vehicle computing device(s) 104, thecomputer-readable media 118 may be a tangible non-transitory medium tothe extent that, when mentioned, non-transitory computer-readable mediaexclude media such as energy, carrier signals, electromagnetic waves,and/or signals per se. In some cases, the computer-readable media 118may be at the same location as the vehicle computing device 104, whilein other examples, a portion of the computer-readable media 118 may beremote from the vehicle computing device 104.

The computer-readable media 118 may be used to store any number offunctional components that are executable by the processor(s) 116. Inmany implementations, these functional components comprise instructionsor programs that are executable by the processor(s) 116 and that, whenexecuted, specifically program the processor(s) 116 to perform theactions attributed herein to the vehicle computing device 104.Functional components stored in the computer-readable media 118 mayinclude the vehicle control program 124, the route selection program126, and the localization program 128, each of which may include one ormore computer programs, applications, executable code, or portionsthereof. Further, while these programs are illustrated together in thisexample, during use, some or all of these programs may be executed onseparate vehicle computing device(s) 104. Alternatively, in someexamples, each of these programs 124, 126 and 128 may be part of asingle program.

In addition, the computer-readable media 118 may store data, datastructures, machine-learning models, and other information used forperforming the functions and services described herein. For example, thecomputer-readable media 118 may store one or more route predictionmachine-learning models (MLMs) 130 that may be used by the routeselection program 126 during route selection. Additionally, thecomputer-readable media 118 may store sensor data 132 received from theonboard sensors 112, and which may include information about landmarksdetected during a trip. In addition, the computer-readable media 118 maystore landmark data 134, which may be received from the servicecomputing device(s) 108, as discussed additionally below. Furthermore,the computer-readable media 118 may store sensor configurationinformation 136, which may indicate the current type, field of view, andstatus of the onboard sensors 112. Further, the computer-readable media118 may store safety scores 138, which may be received from the servicecomputing device(s) 108, as discussed additional below.

Further, while the data, data structures and MLM(s) are illustratedtogether in this example, during use, some or all of these elements maybe stored on separate ones of the computing device(s) 104. The computingdevice(s) 104 may also include or maintain other functional componentsand data, which may include programs, drivers, etc., and the data usedor generated by the functional components. Further, the computingdevice(s) 104 may include many other logical, programmatic, and physicalcomponents, of which those described above are merely examples that arerelated to the discussion herein.

The one or more communication interfaces 120 may include one or moresoftware and hardware components for enabling communication with variousother devices, such as over the CAN bus and/or over one or morenetwork(s) 106. For example, the communication interface(s) 120 mayenable communication through one or more of a LAN, the Internet, cablenetworks, cellular networks, wireless networks (e.g., Wi-Fi) and wirednetworks (e.g., CAN, Fibre Channel, fiber optic, Ethernet), directconnections, as well as close-range communications such as BLUETOOTH®,and the like, as additionally enumerated elsewhere herein.

The one or more networks 106 may include any appropriate network,including a wireless network, such as a cellular network; a wide areanetwork, such as the Internet; a local area network, such an intranet; alocal wireless network, such as Wi-Fi; close-range wirelesscommunications, such as BLUETOOTH®; a wired network, including fiberoptics and Ethernet; any combination thereof, or any other suitablecommunication network. Components used for such communicationtechnologies can depend at least in part upon the type of network, theenvironment selected, or both. Protocols for communicating over suchnetworks are well known and will not be discussed herein in detail.

The sensor data 132 may include sensor data received from the onboardsensors 112. For example, the onboard sensors 112 may include any of aplurality of different types of sensors such as a camera system, radar,LIDAR, ultrasound, a global navigation satellite system (GNSS) receiver(referred to hereinafter by the common usage name “GPS”, which is alsointended to be inclusive of any other satellite navigation system),accelerometers, a compass, and the like. In addition, the sensor data132 used by the vehicle control program 118 may include informationreceived from or associated with various vehicle systems 114, such as(not shown in FIG. 1 ) from a suspension controller associated with thesuspension system, a steering controller associated with the steeringsystem, a vehicle speed controller associated with a braking andacceleration system, and so forth.

For example, the vehicle control program 118 may use rule-based and orartificial-intelligence-based control algorithms to determine parametersfor vehicle control. For instance, the vehicle control program 118 maydetermine an appropriate action, such as braking, steering,accelerating, or the like, and may send one or more control signals toone or more vehicle systems 114 based on the determined action. Forexample, the vehicle control program 118 may send control signals to thesuspension controller, the steering controller, and/or the vehicle speedcontroller for controlling or partially controlling the vehicle in someapplications.

The service computing device(s) 108 may include one or more servers orother types of computing devices that may be embodied in any number ofways. For instance, in the case of a server, the programs, otherfunctional components, and data may be implemented on a single server, acluster of servers, a server farm or data center, a cloud-hostedcomputing service, and so forth, although other computer architecturesmay additionally or alternatively be used.

Further, while the figures illustrate the functional components and dataof the service computing device 108 as being present in a singlelocation, these components and data may alternatively be distributedacross different computing devices and different locations in anymanner. Consequently, the functions may be implemented by one or moreservice computing devices, with the various functionality describedherein distributed in various ways across the different computingdevices. Multiple service computing devices 108 may be located togetheror separately, and organized, for example, as virtual servers, serverbanks, and/or server farms. The described functionality may be providedby the servers of a single entity or enterprise, or may be provided bythe servers and/or services of multiple different entities orenterprises.

In the illustrated example, each service computing device 108 mayinclude one or more processors 140, one or more computer-readable media142, and one or more communication interfaces 144. Each processor 140may be a single processing unit or a number of processing units, and mayinclude single or multiple computing units or multiple processing cores.The processor(s) 140 can be implemented as one or more microprocessors,microcomputers, microcontrollers, digital signal processors, centralprocessing units, state machines, logic circuitries, and/or any devicesthat manipulate signals based on operational instructions. For instance,the processor(s) 140 may be one or more hardware processors and/or logiccircuits of any suitable type specifically programmed or configured toexecute the algorithms and processes described herein. The processor(s)140 can be configured to fetch and execute computer-readableinstructions stored in the computer-readable media 142, which canprogram the processor(s) 140 to perform the functions described herein.

The computer-readable media 142 may include volatile and nonvolatilememory and/or removable and non-removable media implemented in any typeof technology for storage of information, such as computer-readableinstructions, data structures, program modules, or other data. Suchcomputer-readable media 142 may include, but is not limited to, RAM,ROM, EEPROM, flash memory or other memory technology, optical storage,solid state storage, magnetic tape, magnetic disk storage, storagearrays, network attached storage, storage area networks, cloud storage,or any other medium that can be used to store the desired informationand that can be accessed by a computing device. Depending on theconfiguration of the service computing device 108, the computer-readablemedia 142 may be a type of computer-readable storage media and/or may bea tangible non-transitory media to the extent that when mentionedherein, non-transitory computer-readable media exclude media such asenergy, carrier signals, electromagnetic waves, and signals per se.

The computer-readable media 142 may be used to store any number offunctional components that are executable by the processors 140. In manyimplementations, these functional components comprise instructions orprograms that are executable by the processors 140 and that, whenexecuted, specifically configure the one or more processors 140 toperform the actions attributed above to the service computing device108. Functional components stored in the computer-readable media 142 mayinclude a navigation information program 146 that may be executed toconfigure the service computing device 108 to determine and sendnavigation information, such as safety scores 138 and landmark data 134,to the vehicle computing device 104. For example, the navigationinformation program 146 may configure the service computing device 140to retrieve landmark data from a landmark database 148 or other landmarkdata structure, and send the landmark data 134 to one or more of thevehicles 102 for use in localizing the vehicle with respect to maplocation.

In some examples, the service computing device 108 may receive thesensor data 132 including landmark detection information from aplurality of vehicles 102 that traverse the same travel path. Theservice computing device may aggregate the landmark information from aplurality of vehicles 102 to enable detection and identification of theparticular landmarks more accurately, and for determining whichlandmarks are detectable under which types of local conditions.

In addition, the computer-readable media 142 may store data used forperforming the operations described herein. Thus, the computer-readablemedia 142 may include the landmark database 148, as discussed above. Inaddition, the computer-readable media 142 may store one or more MLMs,such as a safety score MLM 150, a localization MLM 152, and a landmarkupdate MLM 154, as discussed additionally below. In addition, thecomputer-readable media 142 may store a vehicle database 156 that mayinclude information about each vehicle that uses the system 100, whichmay include contact information and the sensor configuration information136. Further, the service computing device 108 may also include ormaintain other functional components and data not specifically shown inFIG. 2 , which may include programs, drivers, etc., and the data used orgenerated by the functional components. Additionally, the servicecomputing device 108 may include many other logical, programmatic, andphysical components, of which those described above are merely examplesthat are related to the discussion herein. Examples of MLMs that may beused in some examples herein may include predictive models, decisiontrees, classifiers, regression models, such as linear regression models,support vector machines, stochastic models, such as Markov models andhidden Markov models, and artificial neural networks, such asself-organizing neural networks, recurrent neural networks,convolutional neural networks, modular neural networks, and so forth.

The communication interface(s) 144 may include one or more interfacesand hardware components for enabling communication with various otherdevices, such as over the network(s) 106. For example, communicationinterface(s) 144 may enable communication through one or more of theInternet, cable networks, cellular networks, wireless networks (e.g.,Wi-Fi) and wired networks (e.g., fiber optic and Ethernet), as well asclose-range communications, such as BLUETOOTH®, BLUETOOTH® low energy,and the like, as additionally enumerated elsewhere herein.

The information source computing device(s) 110 may include a hardwareconfigurations similar to the service computing devices 108 describedabove, but with different functional components and data stored thereonor associated there with. For example, the information source computingdevices 110 may store and provide local condition data that may beprovided to the service computing device 108 for indicating the currentcondition of specified road segments as discussed additionally below.

As one example, the vehicle computing device 104 may provide source anddestination information 164 for a trip to the service computing device108. In response, when analyzing possible routes, the service computingdevice 108 may request local condition data 162 for the possible routesfrom the information source computing devices 110 to determine currentconditions on the possible routes. The service computing device may userthe local condition data to determine the safety scores 138 for thepossible routes and may send the safety scores to the vehicle computingdevice 104. The vehicle computing device 104 may determine a selectedroute based at least in part on the safety scores 138. The servicecomputing device may further determine landmark data 134 for theselected route, and may send the landmark data 134 to the vehiclecomputing device 104 to enable the vehicle to localize itself whiletraversing the selected route. Additional details are discussed below.

FIGS. 2, 4-6, 8 and 10 include flow diagrams illustrating exampleprocesses according to some implementations. The processes areillustrated as collections of blocks in logical flow diagrams, whichrepresent a sequence of operations, some or all of which can beimplemented in hardware, software or a combination thereof. In thecontext of software, the blocks may represent computer-executableinstructions stored on one or more computer-readable media that, whenexecuted by one or more processors, program the processors to performthe recited operations. Generally, computer-executable instructionsinclude routines, programs, objects, components, data structures and thelike that perform particular functions or implement particular datatypes. The order in which the blocks are described should not beconstrued as a limitation. Any number of the described blocks can becombined in any order and/or in parallel to implement the process, oralternative processes, and not all of the blocks need be executed. Fordiscussion purposes, the processes are described with reference to theenvironments, systems, and devices described in the examples herein,although the processes may be implemented in a wide variety of otherenvironments, systems, and devices.

FIG. 2 is a flow diagram illustrating an example process 200 fordetermining an optimal route according to some implementations. In someexamples, the process 200 may be executed by the system 100 discussedabove. For example, a portion of the process 200 may be executed by thevehicle computing devices 104, and another portion of the process 200may be executed by the service computing devices 108, as indicated bythe dashed line. Furthermore, while in this example, certain functionsare being illustrated as being performed by one or the other of thecomputing devices 104 or 108, respectively, it will be readily apparentto those of skill in the art having the benefit of the disclosure hereinthat some of the functions may be performed by the other one of thecomputing devices 104 or 108.

At 202, the vehicle computing device 104 may receive navigation inputand/or voice input from a vehicle occupant for determining adestination. For example, the route selection program may be executed todetermine whether a destination has been provided by a user at the startof a trip. If the destination is not provided, the vehicle computingdevice 104 may query the user via a voice communication HMI, via a textprompt presented on a display screen, or the like.

At 204, the vehicle computing device 104 may determine the destinationfor the trip. For example, based on received inputs from the user and/orbased on execution of a destination prediction algorithm, the vehiclecomputing device 104 may determine a destination for the trip. In someexamples, a voice communication function of the HMI may providesuggestions to the user based on a predicted destination, inputsreceived from the user, and so forth, for determining and confirming thedestination.

At 206, the vehicle computing device 104 may determine user preferencesfor the trip. For example, the vehicle computing device may refer todefault user preferences, preloaded user preferences, or the vehiclecomputing device may query the user regarding the user preferences toidentify the user preferences for the current trip. As severalnonlimiting example, the user preferences may be categorized in aplurality of categories, such as safety, comfort, efficiency, time todestination, cost, and the like, which may be used during routeselection, as discussed additionally below.

At 208, the vehicle computing device 104 may send the source anddestination information to the service computing device 108. Inaddition, the vehicle computing device 104 may send sensor configurationinformation 136 to the service computing device 108 if the servicecomputing device 108 does not already have this information in thevehicle database 156.

At 210, the service computing device 108 may receive the source anddestination information sent by the vehicle computing device 104.

At 212, the service computing device 108 may receive or may accessvehicle sensor configuration information for the vehicle from which theroute and road segment information was received. As mentioned above, insome examples, the vehicle computing device 104 may send the sensorinformation to the service computing device 108. In other examples, theservice computing device 108 may maintain a vehicle database, and mayaccess the sensor configuration information in the vehicle database ifthe service computing device 108 as previously received the sensorconfiguration information from the vehicle.

At 214, the service computing device 108 may determine feasible routesfor the trip. For instance, the service computing device 108 maydetermine all possible feasible routes between the source location andthe destination location. Typically, there may be a plurality ofseparate routes available between the source location and thedestination location. When there are a large number of feasible routes,the service computing device 108 may narrow down the feasible routes toa smaller number based on various criteria such as a distance differencethreshold or the like.

At 216, the service computing device 108 may determine multiple feasibleroad segments based on the feasible routes identified at 208 above. FIG.3 , discussed below, illustrates an example of routes and road segments.

At 218, the service computing device 108 may get additional informationrelated to the route and road segments over the network(s) 106. Forexample, the service computing device may connect over the one or morenetworks 106 to a web server or other information source computingdevice 110 to obtain additional information about local conditionsrelated to the route and road segments determined for the vehicle 102.For example, as indicated at 219, the service computing device 108 mayreceive additional information such as weather conditions, trafficconditions, time information, lighting conditions, and so forth.

At 220, the service computing device 108 may receive landmarkinformation from the landmark database. For example, the servicecomputing device 108 may access the landmark database to obtaininformation about landmarks corresponding to the received route and roadsegment information.

At 222, the service computing device 108 may perform an AI basedlandmark selection and weight estimation. For example, the servicecomputing device 108 may select landmarks from the landmark database anddetermine a corresponding weight for each landmark along the segmentdepending on the factors mentioned above. The corresponding weights forall the landmarks along each road segment may be used to determine thesafety score of the segment. Details of the landmark selection andweight estimation are discussed additionally below, e.g., with respectto FIG. 4 .

At 224, the service computing device 108 may estimate a safety score foreach of the multiple road segments. As mentioned above, thecorresponding weights for all the landmarks along each road segment maybe used to determine the safety score of the segment. Details of thesafety score estimation are discussed additionally below, e.g., withrespect to FIG. 4 .

At 226, the service computing device 108 may determine whether thedestination is reached by the selected road segments. If so, the processgoes to 230. If not, the process goes back to 228 to select a differentroad segment or route, such as a next best segment or route.

At 230, the service computing device 108 may estimate a safety score forall the feasible routes determined for the vehicle 102, and may send thesafety scores to the vehicle computing device 104.

At 232, the vehicle computing device 104 may determine a predicted routebased on the safety scores. For example, the safety scores received fromthe service computing device 108 may be used for route prediction inconjunction with various other scores for various other factors, such astime, cost, efficiency, comfort, etc., for all routes. The routeprediction program may first weight the scores for the factors based onthe user preferences determined at 206, and may optimize a cost functionto identify the optimal route to the destination location. Based on theuser preferences, the predicted route may not necessarily be the safestroute to the destination location. Details of determining the predictedroute are discussed additionally below, e.g., with respect to FIG. 5 .

At 234, the service computing device 108 may receive the predicted routefrom the vehicle computing device 104, may set landmarks forlocalization for the predicted route, and may send the landmarks to thevehicle computing device 104. For example, because the predicted routemay not necessarily be the safest route of the feasible routes, theservice computing device 108 may execute a localization MLM, or otherlocalization algorithm, to identify the effective landmarks on theroutes in order to enable the vehicle to localize itself accurately. Thepredicted route information may be used to select the effectivelandmarks to be used for localization in given weather conditions, timeof day, lighting conditions, and traffic conditions. Details of settingthe landmarks for localization are discussed additionally below, e.g.,with respect to FIG. 6 .

At 236, the vehicle computing device 104 may receive the landmarkinformation from the service computing device 108 and may localize thevehicle based on the received landmark information. The localizationprogram 128 may be executed on the vehicle computing device 104 to usethe received landmarks and current sensor data to localize the vehicle102. The localization program 128 may also store the landmarks detectedby the sensors in a local storage. Details of localizing the vehicle 102are discussed additionally below, e.g., with respect to FIG. 8 .

At 238, the vehicle computing device 104 may store information about thelandmarks detected by the sensors during the trip, and may send thestored information about the landmarks detected by the sensors to theservice computing device 108.

At 240, the service computing device 108 may update the landmarkdatabase 148 based on the information about the sensed landmarks sent bythe vehicle computing device 104. For example, the service computingdevice 108 may update the landmark database by comparing the sensor datareceived from the vehicle computing device 104 with the landmark dataalready available in the landmark database. If the landmark alreadyexists in the landmark database, the current landmark score may beupdated based on the given conditions for the trip, such as vehiclesensor configuration, and local condition factors including weatherconditions, time of day, lighting, traffic, etc. If the landmark doesnot already exist in the database, the landmark and its attributes maybe added to the landmark database. Accordingly, the landmark databasemay be continually improved, which also improves the quality of vehiclelocalization. In some examples, the landmark is generated using landmarkdata received from a large number of vehicles that use the servicecomputing device 108 for navigation as described in the process 200.Thus, the landmark database may be enriched with a variety of data asvehicle sensor configuration may vary from sensor to sensor and also thedetection conditions for the landmarks may vary based on variations inthe local conditions. Details about the updating of the landmarkdatabase are discussed additionally below, e.g., with respect to FIG. 10.

FIG. 3 illustrates an example 300 of determining multiple feasible roadsegments according to some implementations. In this example, a sourcelocation 302 and a destination location 304 initially determined, e.g.,as shown on a map 306. For example, after the destination location 304has been set, a plurality of feasible routes may be determined. In thisexample, three feasible routes are illustrated, namely a first route308, a second route 310, and a third route 312. In other examples, moreor fewer feasible routes may be determined. In addition, in the casethat there are a very large number of feasible routes, the number offeasible routes may be narrowed using any of various thresholds such asestimated distance traveled along each route, estimated time of travelfor each route, or the like. In some cases, the narrowing criteria maybe based at least in part on the user preferences.

The feasible routes 308, 310 and 312 may each be segmented into multipleroad segments. For example, the first route 308 is segmented into roadsegments 1-1, 1-2, 1-3 and 1-4; the second route 310 is segmented intoroad segments 2-1, 2-2, 2-3, and 2-4; and the third route 312 issegmented into road segments 3-1, 3-2 and 3-3. The endpoint/startpoint314 of each road segment may typically be an intersection or the like.Multiple feasible road segments originating from the source location 302may be selected for analysis, i.e., road segments 1-1, 2-1 and 3-1, suchas for determining respective safety scores, comfort scores, timescores, cost scores, efficiency scores, or the like, as discussedadditionally below. Furthermore, while a map is illustrated in FIG. 3for discussion purposes, in operation it may not be necessary for theservice computing device 108 to generate a visual map for performing theanalysis of the selected routes and road segments.

As mentioned above, additional information may be requested and receivedfrom the information source computing devices 110 for each road segment,such as weather conditions, time of day, traffic conditions, lightingconditions, etc. The sensor configuration information of the vehicle 102may also be received from vehicle computing device 104 or may beaccessed in a vehicle database 156 as discussed above. The servicecomputing device 108 selects landmarks from the global landmark databaseand determines a corresponding weight for each landmark along thesegment depending, at least partially, on the factors mentioned above.The corresponding weight for each of the landmarks along each roadsegment may be aggregated and used to determine the safety score of thesegment. This process may be performed iteratively until all roadsegments through to the destination location 304 have been analyzed. Thesafety scores of all routes 308, 310 and 312 may be determined byaggregating the respective safety scores of the respective roadsegments.

FIG. 4 is a flow diagram illustrating an example process 400 fordetermining a safety score according to some implementations. In someexamples, the process 400 may be executed by the system 100 discussedabove. For example, the process 400 may be executed by the servicecomputing device(s) 108 by executing the navigation information program146 in some examples. In addition, in some cases, the process 400 maycorrespond in part to blocks 212-230 of the process 200 of FIG. 2discussed above.

At 402, the service computing device 108 may determine feasible routesfor a trip and may determine multiple feasible road segments based onthe feasible routes. For instance, the service computing device 108receives source and destination information from the vehicle computingdevice 104, such as based on execution of the route selection program126 by the vehicle computing device 104. After receiving the source anddestination locations from the vehicle computing device 104, the servicecomputing device 108 may execute the navigation information program 146to determine all possible feasible routes between the source locationand the destination location. The navigation information program 146 maybe executed on the service computing device 108 to determine availableroutes to the destination and to create road segments for each route.Typically, there may be a plurality of separate or branched routesavailable between the source location and the destination location. Whenthere are a large number of feasible routes, the service computingdevice 108 may narrow down the number of feasible routes to a smallernumber based on various criteria such as a distance difference thresholdor time difference threshold based on comparison of each route with theshortest route, or the like. Multiple feasible segments that originatefrom the source location may be selected for analysis, as discussedabove with respect to FIG. 3 .

At 404, the service computing device 108 may get additional informationrelated to the routes and road segments over the network(s) 106. Forexample, the service computing device may connect over the one or morenetworks 106 to a web server or other information source computingdevice 110 to obtain additional information about local conditionsrelated to the route and road segments determined for the vehicle 102.The service computing device 108 may execute the navigation informationprogram 146 to communicate with third party cloud services andinfrastructure or other information source computing devices 110 togather information related to weather (such as rain, fog, snow, clearweather etc.), time of day, lighting conditions, traffic conditions,traffic rules, construction, local events such as street parties,festivals, sporting events, or the like, along the road segments. Forexample, as indicated at 405, the service computing device 108 mayreceive additional information such as weather conditions, trafficconditions, time information, lighting conditions, and so forth, e.g.,as listed above.

At 406, the service computing device 108 may determine, based on theadditional information received over the network(s) 106, the weathercondition for each road segment during the time at which the vehiclewould be expected to traverse each road segment.

At 408, the service computing device 108 may determine, based on theadditional information received over the network(s) 106, the time of dayduring which the vehicle would be expected to traverse each roadsegment.

At 410, the service computing device 108 may determine, based on theadditional information received over the network(s) 106, the lightingcondition for each road segment during the time at which the vehiclewould be expected to traverse each road segment. In addition, whilethree factors, namely weather, time and lighting are discussed in thisexample, other factors that may be used, such as traffic, local eventstaking place, construction, or the like, as listed above, or as will beapparent to those of skill in the art having the benefit of thedisclosure herein.

At 412, the service computing device 108 may access or otherwise receivevehicle sensor configuration information for the vehicle 102. Asmentioned above, in some examples, the vehicle computing device 104 maysend the sensor configuration information to the service computingdevice 108. In other examples, the service computing device 108 maymaintain a vehicle database 156, and may access the sensor configurationinformation in the vehicle database 156 if the service computing device108 has previously received the sensor configuration information fromthe vehicle 102. In some examples, the sensor configuration of thevehicle 102 may include information such as sensor types on the vehicle102 and their corresponding locations on the vehicle 102, field of view,resolution, sampling rate, and so forth.

At 414, the service computing device may determine the type of sensorsonboard the vehicle 102 based on the received vehicle sensorconfiguration information.

At 416, the service computing device 108 may determine the field of viewof each of the sensors included in the vehicle sensor configurationinformation for the vehicle 102.

At 418, the service computing device 108 may receive landmarkinformation from the landmark database 148. For example, the servicecomputing device 108 may access the landmark database 148 to obtaininformation about landmarks corresponding to the route and road segmentsdetermined for the vehicle 102.

At 420, the service computing device 108 may perform an AI basedlandmark selection and weight estimation. For example, the servicecomputing device 108 may execute the navigation information program 146to select landmarks from the landmark database 148 and determine acorresponding weight for each selected landmark along each road segmentdepending, at least in part, on the factors mentioned above. Thecorresponding weights for all the landmarks along each road segment maybe used to determine the safety score of the road segment.

In some examples, the service computing device 108 may input the weathercondition for the road segment, the time of day for the road segment,the lighting condition for the road segment, and so forth into thesafety score MLM 150 (or other type of algorithm) as discussed abovewith respect to FIG. 1 . In some cases, the safety score MLM 150 may betrained, tested and validated using the detection quality scores andother information in the landmark database 148, as described below.

The navigation information program 146 selects landmarks from thelandmark database 148 along the selected road segment being analyzed,and provides a respective corresponding weight for each landmarkdepending on the conditions. The corresponding weight is calculatedbased on the sensor detection uncertainty for the selected landmark, asthe sensor detection quality highly depends on the above-mentionedparameters. For example, weather, lighting, time of day, and so forthmay be fuzzy parameters and do not have clearly defined boundaries. Forinstance, rain or snow might not be clearly classified as less, mediumor heavy for sensor detection quality. Accordingly, implementationsherein apply a threshold for sensor detection quality that may beestimated using machine learning techniques for various conditions. Afew nonlimiting concrete examples are discussed below.

As one example, when roads are covered due to continuous light snowfallin daylight conditions, certain landmarks such as lane markers are notusable in this condition as their detection probability is very low.However, the landmarks such as buildings, poles and trees may still havea sufficient probability of detections and, therefore, these types oflandmarks may be selected for a road segment to generate a safety score.On the other hand, when the weather conditions are good, i.e., no snow,the same lane markers may have higher probability of detection than thatof trees and, therefore, the lane markers may be selected instead of thetrees as landmarks to be used for the safety score calculations.

As another example, suppose that the time of day is night and thelighting condition along the road segment is dark, i.e., there are nostreetlights or insufficient streetlights. Further, suppose that thevehicle is equipped with only camera sensors. When the road segment isdark, the camera sensor field of view may be restricted to only theareas where vehicle's headlights illuminate the road and surroundings.Accordingly, landmarks such as lane markers and traffic signs, such asstop signs, speed limit signs, street signs, and so forth, which havereflective properties and that fall within the field of view of theforward facing camera may have high detection probabilities and,therefore, these landmarks may be selected for the road segment whengenerating the safety score.

As still another example, suppose that the lighting condition is directsunlight on the front of vehicle so that visibility for theforward-facing camera sensor is low. Further, suppose that the vehicleis equipped with radar in addition to the camera sensors. In this case,landmarks that have low detectability using radar might not be selected.Instead landmarks that have high detection probabilities with radar maybe selected for the road segment when generating the safety score forthe road segment.

As still another example, suppose that the time of day is night andlighting condition along the road segment is dark. Further, suppose thatthe vehicle is equipped with lidar and camera sensors. The lidar sensortypically works effectively in the dark and, therefore, landmarks suchas buildings, poles, traffic signs, road curbs which can be effectivelydetected by lidar may be selected for the safety score estimation, aswell as lane markers that may be predicted to be visible due to beingilluminated by the vehicle's headlights.

As still another example, supposed that there are dense trafficconditions along a selected road segment. The detection of road surfacefeatures and traffic signs is difficult due to being blocked fromdetection by other vehicles. Accordingly, landmarks such as buildingsand poles with areas which are typically higher in height than thevehicles on the road may be selected as landmarks for performing thesafety score estimation for the road segment.

In some examples, the safety score MLM 150 may be configured by a usinga maximum likelihood method. However, other techniques and/or othertypes of MLMs may be used, such based on using Bayesian probability forestimating quality of landmark using a Markov Chain rule or the like. Insome examples, the navigation information program 146 may first createsample points along the selected road segment. Then at each samplepoint, the landmark quality may be evaluated for effectiveness forvehicle position estimation using above-discussed parameters, e.g.,weather, lighting, traffic, time etc.

When formulating the landmark data association problem in terms of amaximum likelihood problem, the likelihood function for estimatingvehicle pose using landmark detection may be formulated as a product ofprobability distribution. For example, in 1998, Olson and Matthiesdescribed maximum likelihood estimation techniques for performing roverlocalization in natural terrain by matching range maps. See, Olsen etal., Maximum Likelihood Rover Localization by Matching Range Maps, IEEE,1998. In this paper, the authors defined a probability distribution onlybased on two-dimensional distance to the landmarks. On the other hand,implementations herein employ the maximum likelihood function todetermine a probability distribution for each of the above parametersfor each landmark to determine a probability of detection. Accordingly,the total probability of detection of an individual landmark may changewith changes in parameters, as discussed in the examples above. Once themaximum likelihood for each sample point is estimated the landmarkswhich provide this maximum likelihood are extracted from global landmarkdatabase and their corresponding weights are estimated based ondetection probabilities.

At 422, the service computing device 108 may determine whether theweight of a particular landmark is greater than a threshold weight. Thelandmarks with a weight greater than the threshold may be selected. Ifthe number of landmarks to use for navigation is not insufficient forestimating the safety score, then the threshold may be relaxed, asdiscussed below, and more landmarks may be selected. If the landmarkweight is greater than the threshold, the process may go to 426. If not,the process may go to 424.

At 424, the service computing device may select a next landmark forperforming the AI based weight estimation for the landmarks based on theplurality of factors discussed at 406-410.

At 426, on the other hand, when the landmark weight exceeds thethreshold, the service computing device 108 may determine whether thereare enough landmarks that have exceeded the threshold to determine asafety score for the selected road segment. If not, the process goes to428. If so, the process goes to 430.

At 428, when there are not enough landmarks with weights greater than athreshold to determine a safety score for the selected road segment, theservice computing device 108 may relax the threshold and may go to 424to select a next landmark for analysis using the relaxed threshold.

At 430, when enough landmarks for determining a safety score have beenselected for the particular road segment, the service computing device108 may estimate a safety score for the particular road segment. Thesafety score for each segment may be calculated using the correspondingweights of the selected landmarks. The safety score may be calculated asthe weighted mean of the maximum likelihood for all sample points alongthe road segment and can be defined as follows:

$S_{r} = {\sum\limits_{s_{p} = 0}^{s_{p} = n}\frac{j*{L\left( s_{p} \right)}}{j}}$where S_(r) is the score of the road segment, s_(p) is a sample point onthe road segment, L(s_(p)) is the maximum likelihood of that samplepoint, and j is the number of landmarks around each sample point basedon the field of view of the sensors available on the vehicle.

At 432, the service computing device may select a next segment, if any,and may perform analysis determine a safety score for that segment.After the safety scores for all the feasible road segments aredetermined, the navigation information program 146 may select the nextbest segments to evaluate. The navigation information program 146 mayrecursively evaluate all the segments until the destination is reached.

At 434, the service computing device 108 may determine whether thedestination is reached by the analyzed road segments for which a safetyscore was determined. If so, the process goes to 438. If not, theprocess goes to 436

at 436, when the destination is not reached such as due to not enoughlandmarks or the like, the service computing device 108 may selectdifferent multiple road segments or routes, such as the next best roadsegments or routes, and may return to 404 to analyze the newly selectedroad segments or routes.

At 438, the service computing device 108 may estimate a safety score forall the feasible routes determined for the vehicle computing device 104.For example, the normalized safety score for each route may be generatedand from the road segment scores.

At 440, the service computing device 108 may send the safety scores andcorresponding route information to the vehicle computing device 104. Forexample, the safety scores may be sent to the route prediction programon the vehicle computing device.

FIG. 5 is a flow diagram illustrating an example process 500 fordetermining a predicted route according to some implementations. In someexamples, the process 500 may be executed by the system 100 discussedabove. For example, a portion of the process 500 may be executed by thevehicle computing devices 104, and another portion of the process 500may be executed by the service computing devices 108, as indicated bythe dashed line. Furthermore, while in this example, certain functionsare being illustrated as being performed by one or the other of thecomputing devices 104 or 108, respectively, it will be readily apparentto those of skill in the art having the benefit of the disclosure hereinthat some of the functions may be performed by the other one of thecomputing devices 104 or 108. In addition, in some cases, the process500 may correspond in part to blocks 202-210 and 224-232 of the process200 of FIG. 2 discussed above.

At 502, the vehicle computing device 104 may receive navigation inputand/or voice input from a vehicle occupant for determining adestination. For example, the route selection program may be executed todetermine whether a destination has been provided by a user at the startof a trip. If the destination is not provided, the vehicle computingdevice 104 may query the user via a voice communication HMI, via a textprompt presented on a display screen, or the like.

At 504, the vehicle computing device 104 may determine the destinationfor the trip. For example, based on received inputs from the user and/orbased on execution of a destination prediction algorithm, the vehiclecomputing device 104 may determine a destination for the trip. In someexamples, a voice communication function of the HMI may providesuggestions to the user based on a predicted destination, inputsreceived from the user, and so forth, for determining and confirming thedestination.

At 506, the vehicle computing device 104 may determine user preferencesfor the trip. For example, the vehicle computing device may refer todefault user preferences, preloaded user preferences, or the vehiclecomputing device may query the user regarding the user preferences toidentify the user preferences for the current trip. As severalnonlimiting example, the user preferences may be categorized in aplurality of categories, such as safety, comfort, efficiency, time todestination, cost, and the like, which may be used during routeselection, as discussed additionally below.

At 508, the vehicle computing device 104 may send the source anddestination information to the service computing device 108. Inaddition, the vehicle computing device 104 may send sensor configurationinformation 136 to the service computing device 108 if the servicecomputing device 108 does not already have this information in thevehicle database 156.

At 510, the service computing device 108 may receive the source anddestination information sent by the vehicle computing device 104.

At 512, the service computing device 108 may execute the safety scoreMLM(s) and/or algorithms to determine a safety score for each selectedroute, e.g., as discussed above with respect to FIGS. 2-4 .

At 514, the service computing device 108 may execute comfort scoreMLM(s) and/or algorithms to determine a comfort score for each selectedroute. For example, similar to the process discussed above with respectto FIGS. 2-4 , the navigation information program 146 may be executed bythe service computing device 108 to determine a comfort score for eachroad segment of each route. Examples of factors used for determiningcomfort of a vehicle occupant may include whether a road segment has alarge number of “S” curves, whether the ground is level or wavy, whethera constant speed can be maintained, whether stop and go traffic will beencountered, or the like.

At 516, the service computing device 108 may execute efficiency scoreMLM(s) and/or algorithms to determine an efficiency score for eachselected route. For example, similar to the process discussed above withrespect to FIGS. 2-4 , the navigation information program 146 may beexecuted by the service computing device 108 to determine an efficiencyscore for each road segment of each route. Examples of factors used fordetermining efficiency of a vehicle for a route may include the lengthof a road segment, the number of stops and starts that may be requiredon the road segment, whether the ground is level or hilly, whether aconstant speed can be maintained, whether stop and go traffic will beencountered, or the like.

At 518, the service computing device 108 may execute time score MLM(s)and/or algorithms to determine a time score for each selected route. Forexample, similar to the process discussed above with respect to FIGS.2-4 , the navigation information program 146 may be executed by theservice computing device 108 to determine a time score for each roadsegment of each route. Examples of factors used for determining a timefor a vehicle to traverse a route may include the length of a roadsegment, the number of stops and starts that may be required on the roadsegment, whether a constant speed can be maintained, the speed limit onthe road segment, whether stop and go traffic will be encountered, orthe like.

At 520, the service computing device 108 may execute cost score MLM(s)and/or algorithms to determine a cost score for each selected route. Forexample, similar to the process discussed above with respect to FIGS.2-4 , the navigation information program 146 may be executed by theservice computing device 108 to determine a cost score for each roadsegment of each route. Examples of factors used for determining the costfor a vehicle for a route may include whether any tolls will berequired, and the amount of any tolls, the amount of fuel expected to beused to traverse the route, or the like. Furthermore, while fivepossible types of scores are described in this example, others types ofscores may be used in addition to, or as an alternative to, the scoresdescribed in this example as will be apparent to those of skill in theart having the benefit of the disclosure herein.

At 522, the vehicle computing device 104 receives the safety scores forall routes from the service computing device 108.

At 524, the vehicle computing device 104 receives the comfort scores forall routes from the service computing device 108.

At 526, the vehicle computing device 104 receives the efficiency scoresfor all routes from the service computing device 108.

At 528, the vehicle computing device 104 receives the time scores forall routes from the service computing device 108.

At 530, the vehicle computing device 104 receives the cost scores forall routes from the service computing device 108. Furthermore, whilefive possible types of scores are described in this example, otherstypes of scores may be used in addition to, or as an alternative to, thescores described in this example as will be apparent to those of skillin the art having the benefit of the disclosure herein.

At 532, the vehicle computing device 104 may execute the route selectionprogram 126 to determine a predicted route based on the safety scoresand the other scores received from the service computing device 108. Forexample, the safety scores received from the service computing device108 may be used for route prediction in conjunction with the variousother scores for the various other factors, such as time, cost,efficiency, comfort, etc., for all routes. The route selection program126 may first weight the received scores for the various factors basedon the user preferences determined at 506. For example, the routeselection program 126 receives the user preference informationdetermined at 506 and also receives the respective scores for each routefor safety based on landmark selection, time to travel the route, costof traveling on the route, efficiency of the route, etc., determined bythe service computing device 108. All these factors are weighted basedon the user preferences. For example, if the user preference is forsafety, the safety scores may be weighted higher than the otherparameters for each route. On the other hand, if the user preference isto get the destination as soon as possible, the time score may beweighted higher. Based on the user preferences, the predicted route maynot necessarily be the safest route to the destination location.

In some examples, the route selection program 126 employs a routeprediction MLM 130 or other algorithm that evaluates the weighted scoresagainst pre-determined thresholds based at least in part on a costfunction as follows:J=Σw _(i) *C _(ij)where w_(i) is the user preference weight, C_(ij) is the score or costof the parameter, i is the parameter such as safety, time, cost,efficiency, comfort, etc. and j is the route option. The route J havingthe highest ranked score may be selected as the predicted route.

At 534, after a predicted route is selected by execution of the routeselection program 126, the vehicle computing device 104 may send theroute information for the selected route to the service computing device108 for performing the localization processing for the selected route.

FIG. 6 is a flow diagram illustrating an example process 600 fordetermining landmark data for localization according to someimplementations. In some examples, the process 600 may be executed bythe system 100 discussed above. For example, the process 600 may beexecuted by the service computing device(s) 108 by executing thenavigation information program 146 in some examples. In addition, insome cases, the process 600 may correspond in part to block 234 of theprocess 200 of FIG. 2 discussed above.

At 602, the service computing device 108 may receive the predicted routefrom the vehicle computing device 104. The service computing device 108may also receive a current location of the vehicle 102, which maycorrespond to a portion of the predicted route.

At 604, the service computing device 108 may determine a current roadsegment for the predicted route at which the vehicle is currentlylocated. For example, the service computing device 108 may execute thenavigation information program 146 to determine to the road segment thatthe vehicle is on currently based on the route information and thecurrent vehicle information. The road segments may be determined basedon the techniques discussed above.

At 606, the service computing device 108 may determine waypoints for theroad segment of the predicted route. For example, the waypoints may bepositions along the road segment at which the vehicle is able tolocalize itself identifying corresponding landmarks.

At 608, the service computing device may determine selected landmarksfor the predicted route. For example, based on the waypoint information,the localization MLM or other algorithm may be executed to extracts thelandmarks already determined using the safety score MLM 150 discussedabove. For example, the best landmarks for localization on the roadsegment for the current conditions and the vehicle sensor configurationwill have already been determined during calculation of the safetyscores for each road segment, as discussed above.

At 610, the service computing device 108 may determine geometricassociations for landmarks and waypoints for each segment of thepredicted route.

At 612, the service computing device 108 may access or otherwise receivevehicle sensor configuration information.

At 614, the service computing device 108 may determine the field of viewof the vehicle sensors for the particular vehicle.

At 616, the service computing device 108 may determine the geometricshape of the selected landmarks. For example, the geometric shape of alandmark to be detected for localization may be estimated based on thefield of view of the sensor(s) and the sensor configuration of thevehicle for each waypoint. The landmark data for a plurality oflandmarks may be made ready for localization. For example, suppose thatthe vehicle is equipped with stereo camera sensor in front that has ahorizontal FOV of 50 degree and vertical FOV of 20 degree. Based on thisFOV, the landmark data for each waypoint may be generated in such a waythat the area of the landmark that is expected to be visible in the FOVat the waypoint may be set for localization. Examples setting anexpected FOV for localization are discussed below with respect to FIGS.7A and 7B.

At 618, the service computing device 108 may determine landmarks for atleast the current road segment of the predicted route.

At 620, the service computing device 108 may determine the currentvehicle location corresponding to the particular road segment of thepredicted route to send the landmark data to the vehicle computingdevice 104.

At 622, the service computing device 108 may send the landmark data tothe localization program 128 on the vehicle computing device 104. Thelocalization program 128 may determine the current location of thevehicle based on using the received landmark data for matching with thelandmarks at the nearest waypoint to the current location of thevehicle.

FIGS. 7A and 7B illustrate examples of landmark selection based on shapeextraction according to some implementations. As mentioned above, thegeometric shape of a landmark to be detected for localization may beestimated based on the sensor configuration of the vehicle and the FOVof the sensors. Based on this technique, the area of the landmark thatis expected to be visible in the FOV at the waypoint may be set forlocalization.

As illustrated in FIG. 7A, supposed that the vehicle 102 is equippedwith a forward facing stereo camera sensor with horizontal FOV of 50degree and vertical FOV of 20 degree. Accordingly, the landmark data foreach way point may be generated in so that the area of a landmark 704,such as a tree, which is visible in the FOV at the waypoint may be setfor localization as shown in FIG. 7A, which is a rectangle 706 in thisexample. Further, as illustrated in FIG. 7B, for a different landmark708, the geometric shape may be different, i.e., a different shape andsize rectangle 710. Further, while rectangles are shown in theseexample, in other examples, other geometric shapes may be more suitable,depending on the shape and size of the landmark.

FIG. 8 is a flow diagram illustrating an example process 800 forperforming localization according to some implementations. In someexamples, the process 800 may be executed by the vehicle computingdevice(s) 104 by executing the localization program 128 in someexamples. In addition, in some cases, the process 800 may correspond inpart to blocks 236-238 of the process 200 of FIG. 2 discussed above.

At 802, the vehicle computing device 104 may execute the localizationprogram 128 to initialize a current pose and general location for thevehicle 102. For instance, the pose may be determined at least in partbased on compass information and the general location may be determinedbased at least in part on GPS information or the like.

At 804, the vehicle computing device 104 may send the current pose andlocation information to the service computing device 108.

At 806, the vehicle computing device 104 may receive landmark data for acurrent road segment from the service computing device 108. For example,as discussed above with respect to FIG. 6 , in response to sending thecurrent location of the vehicle to the service computing device 108, theservice computing device 108 may send landmark data for enablinglocalization for the current segment to the vehicle computing device104.

At 808, the vehicle computing device 104 may receive, from the onboardsensors 112, current sensor data for the surroundings of the vehicle 102at the vehicle's current location. As one example, based on the landmarkdata received from the service computing device, the localizationprogram 128 may communicate with the vehicle onboard sensors 112. Thelocalization program 128 may identify the quadrants of the vehicle wherethe landmark data indicates that the landmarks are located, and mayactivate sensors or otherwise receive data from the sensors that have aFOV corresponding to the identified quadrants. Thus, in some examples,the localization program 128 may receive or process current sensor dataonly from the sensors corresponding to the identified quadrants whileignoring not receiving or not processing data from sensors correspondingto quadrants that do not contain landmarks.

At 810, the vehicle computing device 104 may match the received sensordata to the landmark data received from the service computing device108. In some examples, after the current sensor data is received by thelocalization program 128, the localization program may associate thedetected landmarks with the landmarks corresponding to a navigation map,such as an HD map, or the like. Some implementations herein may employiterative closest point (ICP) matching for associating the landmark datafor each vehicle quadrant and may then estimate the weighted mean forframe to frame transformation. Other techniques such as normaldistributions transform (NDT) matching, machine learning, or the like,may also be used for data association of landmarks.

In some examples, the localization program 128 may determine the vehicleposition using a Markov chain rule and extended Kalman filter (EKF). Inaddition, techniques such as visual odometry can also be used incombination with the above discussed techniques to perform localization.Numerous other variations will be apparent to those of skill in the arthaving the benefit of the disclosure herein.

Furthermore, the computation time may be considerably reduced by onlyprocessing the sensor data received from certain active quadrants,which, for instance, reduces the ICP computation load. Accordingly,implementations herein are able to achieve high localization accuracy byselecting the landmarks most likely to be recognizable for each waypointbased on the sensor configuration and the external conditions asdiscussed above.

At 812, as discussed above, the vehicle computing device 104 may updatethe vehicle location and pose based on matching the sensor data with thelandmark data and based on matching the landmark data with a navigationmap such as an HD map or the like.

At 814, the vehicle computing device may store the sensor data for thedetected landmarks. For example, the vehicle computing device mayinclude an onboard storage device or the like for storing the sensordata for the matched landmarks. The localization program 128 may storelandmark data for each landmark detected using the received onboardsensor data and may store the landmark data to subsequently upload thedata to the service computing device, such as at the end of each trip.The localization program 128 may further calculate a detection score foreach landmark which may represent the matching quality for the landmark.As one example, the detection score may be determined based on areciprocal of average Euclidian distances between sensor detectedfeatures and landmark features after matching if the landmark alreadyexists in the landmark database 148. For instance, a lower residualerror in matching may signify a better matching quality for a respectivelandmark. The detection score may also depend at least in part on thevehicle sensor configuration active at the time of detection and variousexternal factors.

At 816, the vehicle computing device 104 may send the stored landmarksensor data to the service computing device 108 to be used for updatingthe landmark database. In some examples, the stored landmark sensor datais sent following completion of the trip or at any other suitable time,and may be sent singly, in batches, or the like.

FIG. 9 illustrates an example 900 of sensing landmarks using activesensors corresponding to where the landmarks are expected to beaccording to some implementations. For example, based on the landmarkdata for localization received from the service computing device 108,the localization program 128 may communicate with the vehicle onboardsensors 112. For instance, based on the landmark data, the localizationprogram 128 may identify which quadrants of the vehicle 102 at which thelandmark data indicates landmarks 902 are located. In some examples, thesensors in a quadrant in which there will be no landmarks to detect maybe deactivated. In other examples, rather than deactivating the sensors,the data from the sensors corresponding to the quadrants withoutlandmarks may be ignored or otherwise not processed. Accordingly, thelocalization program 128 may receive and/or process only current sensordata from the active quadrants. For instance, in the example of FIG. 9 ,the first second and third quadrants are active for landmark detection,while the fourth quadrant may be treated as inactive.

The example of FIG. 9 illustrates a possible configuration of sensorcoverage by the onboard sensors 112 for the vehicle 102 according tosome implementations. The vehicle 102 may be equipped with a wide rangeof sensors to detect and recognize landmarks, as well as to detectobstacles, other vehicles, and so forth. Commonly used sensors mayinclude mono cameras, stereo cameras, infrared cameras, radar, LIDAR,lasers, ultrasonic sensors, and so forth. For any specific driverassistance system application or any specific level of drivingautomation, the sensors may be selected based on the advantages anddisadvantages of the sensor type, which may include detection range,type of detection ability, power requirements, cost, amount of datagenerated, and the like. Each sensor type may have advantages anddisadvantages, and thus, different types of sensors may be combined inuse on the vehicle 102 for improving accuracy in various weather orother types of conditions.

As one example, a camera (mono/stereo) might not perform well in thedark or during inclement weather conditions, and the detection range maybe comparatively low compared to similarly priced radar sensors.However, a radar sensor might not be able to detect a human and may havedifficulty in detecting lane markers. On the other hand, a radar sensormay be a good candidate for long-range detection of other vehicles, ascompared to other sensor types. As another example, an infrared cameramay perform well under night conditions, but may also suffer from poorlong-distance-detection capability. Additionally, a LIDAR sensor mayperform well under night and day conditions, but may be costly and maygenerate huge amounts of data that may require a high capacity processorto process the data in real time. Further, while ultrasonic sensors arelower in cost than some other types of sensors, the detection range ofultrasonic sensors may be 10 meters or less, which may limit theirusefulness. In view of the foregoing, multiple different sensor typesare typically employed for ADAS/AD vehicles to continuously monitor thevehicle surroundings.

In the example of FIG. 9 , the vehicle 102 is equipped with multipledifferent sensors for 360-degree monitoring of the vehicle surroundings.In this example, the vehicle 102 may be equipped with four surround monocameras and/or radar sensors, each a having a respective approximatedetection area 904. The vehicle 102 may also be equipped with aforward-facing mono or stereo camera having an approximate detectionarea 906 in front of the vehicle 102. Additionally, the vehicle 102 maybe equipped with a long range radar sensor having an approximatedetection area 910 in front of the ADAS/AD vehicle 120. In some cases, aLIDAR sensor may be used in place of, or in addition to, one or more ofthe stereo camera, the long-range radar, or others of theabove-discussed sensors. Further, while several example sensorconfigurations are discussed with respect to FIG. 9 , numerous othersensor types, locations, and configurations will be apparent to those ofskill in the art having the benefit of the disclosure herein.Accordingly, implementations herein are not limited to any particularsensor types, locations, or configurations.

FIG. 10 is a flow diagram illustrating an example process 1000 forupdating the landmark database according to some implementations. Insome examples, the process 1000 may be executed by the system 100discussed above. For example, the process 1000 may be executed by theservice computing device(s) 108 by executing the navigation informationprogram 146 and the landmark update MLMs 154 or other algorithms in someexamples. In addition, in some cases, the process 1000 may correspond inpart to block 240 of the process 200 of FIG. 2 discussed above.

As one example, when the destination location has been reached, thelocalization program 128 may determine that the vehicle has reached theend of the trip and may upload the stored landmark data from the vehicle102 to the service computing device 108. The navigation informationprogram 146 may receive the landmark information from the vehiclecomputing device 104 and may employ the landmark update MLM 154 or othersuitable algorithm for updating the landmark database 148 based on thelandmark data received from the vehicle 102.

At 1002, the service computing device 108 may receive the landmark datadetected by the vehicle sensors 112 during the trip.

At 1004, for each landmark about which data is received, the servicecomputing device 108 may determine whether the landmark already existsin the landmark database 148. If so, the process goes to 1006. If not,the process goes to 1022.

At 1006, when the landmark already exists in the landmark database 148,the service computing device 108 may update a detection quality scorefor the landmark in the landmark database 148 for the particularlandmark.

If the landmark does not already exist in the landmark database, adetection quality score for the landmark may be determined based on theexternal conditions and vehicle sensor configuration, such as by usingmaximum likelihood method discussed above, e.g., with respect to FIG. 4. Furthermore, the landmark attributes may be extracted by the landmarkupdate MLM 154 or other suitable algorithm, and the details of thelandmark data for the new landmark may be added to the landmark database148.

At 1008, the service computing device 108 may get additional informationrelated to the trip over the network(s) 106. For example, the servicecomputing device may connect over the one or more networks 106 to a webserver or other information source computing device 110 to obtainadditional information about local conditions related to the trip. Forexample, as indicated at 1009, the service computing device 108 mayreceive additional information such as weather conditions, trafficconditions, time information, lighting conditions, and so forth, e.g.,as listed above.

At 1010, the service computing device 108 may determine, based on theadditional information received over the network(s) 106, the weathercondition for a road segment during the trip corresponding to the newlandmark.

At 1012, the service computing device 108 may determine, based on theadditional information received over the network(s) 106, the time of dayduring which the vehicle traversed the road segment corresponding to thenew landmark.

At 1014, the service computing device 108 may determine, based on theadditional information received over the network(s) 106, the lightingcondition for the road segment corresponding to the new landmark. Inaddition, while three factors, namely weather, time and lighting arediscussed in this example, various other factors may be used, such astraffic, local events taking place, construction, or the like, as listedabove, or as will be apparent to those of skill in the art having thebenefit of the disclosure herein.

At 1016, the service computing device 108 may access or otherwisereceive vehicle sensor configuration information for the vehicle 102. Asmentioned above, in some examples, the vehicle computing device 104 maysend the sensor configuration information to the service computingdevice 108. In other examples, the service computing device 108 maymaintain a vehicle database 156, and may access the sensor configurationinformation in the vehicle database 156 if the service computing device108 has previously received the sensor configuration information fromthe vehicle 102. In some examples, the sensor configuration of thevehicle 102 may include information such as sensor types onboard thevehicle 102 and their corresponding locations on the vehicle 102, fieldof view, resolution, sampling rate, and so forth.

At 1018, the service computing device may determine the type of sensorsonboard the vehicle 102 based on the received vehicle sensorconfiguration information.

At 1020, the service computing device 108 may determine the field ofview of each of the sensors included in the vehicle sensor configurationinformation for the vehicle 102.

At 1022, the service computing device 108 may perform AI based landmarkparameter estimation. For example, the service computing device 108 maydetermine a detection quality score for the new landmark based on theexternal conditions and vehicle sensor configuration, such as by usingthe maximum likelihood method discussed above, e.g., with respect toFIG. 4 . Furthermore, the landmark attributes may be extracted by thelandmark update MLM 154 or other suitable algorithm.

At 1024, the service computing device 108 may update the landmarkdatabase by adding new landmark and the details of the new landmark tothe database 148.

FIG. 11 illustrates an example data structure 1100 of landmarkinformation stored in the landmark database 148 according to someimplementations. In some cases, the landmark database 148 may includeinformation about various types of landmarks such as buildings, trees,road surface features, curbs, poles, traffic signs, structures etc. Eachlandmark added to the database 148 may include attributes including butnot limited to type of landmark, location of landmark, geometricdefinition, material properties (if applicable), features (such as edgeinformation, point cloud data, etc.), and so forth. In addition, eachlandmark may include a detection quality score that may be continuallyupdated based on detectability and various types of conditions.

In the illustrated example, the data structure 1100 includes attributes1102, description 1104, and detection quality score 1106. Thedescription 1104 indicates that the landmark is a stop line at anintersection with a detection quality score 1106 of 0.0314. Otherattributes 1102 of the landmark that may be included in the databaseinclude the geometry and location of the landmark.

FIG. 12 illustrates an example data structure 1200 of landmarkinformation stored in the landmark database according to someimplementations. In this example, the landmark is a standard lane on aroad having a left lane border and a right lane border as indicated bythe description 1104. Furthermore, in this example, the data structure1200 for the landmark includes two detection quality scores 1106, i.e. adetection score of 0.0023 for the left lane marker and a detection scoreof 0.0453 for the right lane marker. Additional attributes 1102 includedfor this landmark may include curvature, lane border type, locations ofthe left and right lane borders, material, and color.

FIG. 13 illustrates an example data structure 1300 of landmarkinformation stored in the landmark database according to someimplementations. In this example, the landmark is a wall of a buildingas indicated by the description 1104. In this example, the detectionquality score 1106 for the wall is 0.0013. Additional attributes for thelandmark may include the wall geometry, wall features, wall color andwall location.

FIG. 14 illustrates an example data structure 1400 of landmarkinformation stored in the landmark database according to someimplementations. In this example, the landmark is a stop sign having adetection quality score of 0.23, indicating that the stop sign is highlydetectable in many types of conditions. Additional attributes for thelandmark include the color, shape, heading, geometry and location.Furthermore, while several example landmarks have been described herein,numerous other types of landmarks will be apparent to those of skill inthe art having the benefit of the disclosure herein.

The example processes described herein are only examples of processesprovided for discussion purposes. Numerous other variations will beapparent to those of skill in the art in light of the disclosure herein.Further, while the disclosure herein sets forth several examples ofsuitable frameworks, architectures and environments for executing theprocesses, the implementations herein are not limited to the particularexamples shown and discussed. Furthermore, this disclosure providesvarious example implementations, as described and as illustrated in thedrawings. However, this disclosure is not limited to the implementationsdescribed and illustrated herein, but can extend to otherimplementations, as would be known or as would become known to thoseskilled in the art.

Various instructions, processes, and techniques described herein may beconsidered in the general context of computer-executable instructions,such as computer programs and applications stored on computer-readablemedia, and executed by the processor(s) herein. Generally, the termsprogram and application may be used interchangeably, and may includeinstructions, routines, modules, objects, components, data structures,executable code, etc., for performing particular tasks or implementingparticular data types. These programs, applications, and the like, maybe executed as native code or may be downloaded and executed, such as ina virtual machine or other just-in-time compilation executionenvironment. Typically, the functionality of the programs andapplications may be combined or distributed as desired in variousimplementations. An implementation of these programs, applications, andtechniques may be stored on computer storage media or transmitted acrosssome form of communication media.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described. Rather,the specific features and acts are disclosed as example forms ofimplementing the claims.

What is claimed:
 1. A system comprising: one or more processors; and oneor more non-transitory computer-readable media including executableinstructions, which, when executed by the one or more processors,configure the one or more processors to perform operations comprising:receiving, by the one or more processors, from a vehicle computingdevice of a vehicle, a source location and a destination location;determining, by the one or more processors, a plurality of candidateroutes between the source location and the destination location;determining, by the one or more processors, a plurality of landmarksalong each candidate route between the source location and thedestination location; determining, by the one or more processors,current conditions corresponding to the plurality of landmarks alongeach candidate route, the current conditions including at least one of aweather condition, a lighting condition, a time condition, or a trafficcondition; receiving, by the one or more processors, vehicle sensorconfiguration information for a plurality of sensors onboard thevehicle; determining, by the one or more processors, for individuallandmarks of the plurality of landmarks along each candidate route, andbased on the sensor configuration information and the currentconditions, a probability of detection of the individual landmarks bymultiple ones of the sensors of the plurality of sensors onboard thevehicle; determining, by the one or more processors, respective scoresfor individual candidate routes of the plurality of candidate routesbased on the probability of detection of the individual landmarks of theplurality of landmarks along each candidate route by multiple ones ofthe sensors of the plurality of sensors onboard the vehicle; sending, bythe one or more processors, to the vehicle computing device, and basedat least on the respective scores determined for the individualcandidate routes, information related to at least one candidate routethat at least in part causes the vehicle computing device to select oneof the at least one candidate route as a selected route between thesource location and the destination location; receiving, by the one ormore processors, the selected route from the vehicle computing device;determining, by the one or more processors, geometric associations forlandmarks along the selected route; and sending, by the one or moreprocessors, the geometric associations for the landmarks to the vehiclecomputing device, the sending the geometric associations for thelandmarks to the vehicle computing device causing at least in part thevehicle computing device to select one or more of the sensors of theplurality of sensors onboard the vehicle and utilize the selected one ormore sensors for locating the landmarks along the selected route basedat least on the geometric associations, the vehicle computing devicedetermining a location of the vehicle for performing navigation based atleast in part on locating the landmarks along the selected route via theselected one or more sensors.
 2. The system as recited in claim 1, theoperations further comprising: segmenting each candidate route of theplurality of candidate routes into a plurality of road segments; anddetermining the current conditions by determining the current conditionsfor respective road segments of the plurality of road segments for eachcandidate route.
 3. The system as recited in claim 1, the operation ofdetermining respective scores for the individual candidate routes of theplurality of candidate routes further comprising: determining respectivesafety scores for the individual candidate routes based at least on theprobability of detection of the individual landmarks along each of theindividual candidate routes; and sending the respective safety scoresfor one or more of the candidate routes to the vehicle computing deviceto cause in part, the vehicle computing device to determine the selectedroute between the source location and the destination location based inpart on the respective safety scores for the one or more candidateroutes.
 4. The system as recited in claim 3, wherein, following locatingthe landmarks along the selected route based at least in part on thegeometric associations, the vehicle computing device determines thelocation of the vehicle based in part on associating the locatedlandmarks with corresponding landmarks on a navigation map.
 5. Thesystem as recited in claim 3, wherein determining the respective safetyscores further comprises: segmenting each candidate route of theplurality of candidate routes into a plurality of road segments;determining the current conditions by determining the current conditionsfor respective road segments of the plurality of road segments for eachcandidate route; determining weights for individual landmarks based atleast on the current conditions for the respective road segments, theweights corresponding at least in part to the probability of detectionof the individual landmarks; determining a safety score for individualroad segments based on the weights of the plurality of landmarkscorresponding to the individual road segments; and determining thesafety score for the at least one candidate route by aggregatingrespective safety scores of the individual road segments that comprisethe at least one candidate route.
 6. The system as recited in claim 1,wherein determining, based on the sensor configuration information andthe one or more current conditions, the probability of detection of theindividual landmarks by multiple ones of the sensors further comprises:determining a type of the sensors onboard the vehicle and a field ofview of the sensors onboard the vehicle, and determining a probabilitythat multiple different types of the sensors are able to detect theindividual landmark.
 7. The system as recited in claim 1, the operationsfurther comprising: receiving, from the vehicle computing device, sensordata indicating the landmarks detected during traversal of the selectedroute; and updating an indication of the probability of detection of oneor more of the landmarks in a landmark database based at least in parton the received sensor data.
 8. A method comprising: receiving, by oneor more processors, from a vehicle computing device of a vehicle,location information including a source location and a destinationlocation; determining, by the one or more processors, a plurality ofcandidate routes between the source location and the destinationlocation; determining, by the one or more processors, based on thelocation information, a plurality of landmarks along each candidateroute between the source location and the destination location;determining, by the one or more processors, one or more currentconditions corresponding to the plurality of landmarks along eachcandidate route; receiving, by the one or more processors, sensorconfiguration information for a plurality of sensors onboard thevehicle; determining, by the one or more processors, for individuallandmarks of the plurality of landmarks along each candidate route, andbased on the sensor configuration information and the one or morecurrent conditions, a probability of detection of the individuallandmarks by multiple ones of the sensors of the plurality of sensorsonboard the vehicle; determining, by the one or more processors,respective scores for individual candidate routes of the plurality ofcandidate routes based on the probability of detection of the individuallandmarks of the plurality of landmarks along each candidate route bymultiple ones of the sensors of the plurality of sensors onboard thevehicle; sending, by the one or more processors, to the vehiclecomputing device, and based at least on the respective scores determinedfor the individual candidate routes, information related to at least onecandidate route that at least in part causes the vehicle computingdevice to select one of the at least one candidate route as a selectedroute between the source location and the destination location;receiving, by the one or more processors, the selected route from thevehicle computing device; determining, by the one or more processors,geometric associations for landmarks along the selected route; andsending, by the one or more processors, the geometric associations forthe landmarks to the vehicle computing device, the sending the geometricassociations for the landmarks to the vehicle computing device causingat least in part the vehicle computing device to select one or more ofthe sensors of the plurality of sensors onboard the vehicle and utilizethe selected one or more sensors for locating the landmarks along theselected route based at least on the geometric associations, the vehiclecomputing device determining a location of the vehicle for performingnavigation based at least in part on locating the landmarks along theselected route via the selected one or more sensors.
 9. The method asrecited in claim 8, further comprising: receiving the one or morecurrent conditions over a network from one or more computing devices,the one or more current conditions including one or more of: weatherconditions, lighting conditions, a time of day, traffic conditions,construction taking place, or local events taking place.
 10. The methodas recited in claim 8, wherein determining, based on the sensorconfiguration information and the one or more current conditions, theprobability of detection of the individual landmarks by multiple ones ofthe sensors further comprises: determining a type of the sensors onboardthe vehicle and a field of view of the sensors onboard the vehicle, anddetermining a probability that multiple different types of the sensorsare able to detect the individual landmark.
 11. The method as recited inclaim 8, further comprising: segmenting each candidate route of theplurality of candidate routes into a plurality of road segments; anddetermining the current conditions by determining the current conditionsfor respective road segments of the plurality of road segments for eachcandidate route.
 12. The method as recited in claim 8, wherein,following locating the landmarks along the selected route based at leastin part on the geometric associations, the vehicle computing devicedetermines the location of the vehicle based in part on associating thelocated landmarks with corresponding landmarks on a navigation map. 13.The method as recited in claim 8, further comprising: receiving, fromthe vehicle, sensor data indicating the landmarks detected duringtraversal of the selected route; and updating an indication of theprobability of detection of one or more of the landmarks in a landmarkdatabase based at least in part on the received sensor data.
 14. Themethod as recited in claim 8, further comprising: determining at leastone road segment for each candidate route; determining weights for theindividual landmarks based at least on the current conditions forrespective road segments, the weights corresponding at least in part tothe probability of detection of the individual landmarks; determining,by the one or more processors, a plurality of candidate routes betweenthe source location and the destination location; determining a safetyscore for individual road segments based on the weights of respectivelandmarks corresponding to the individual road segments; determining asafety score for the at least one candidate route by aggregatingrespective safety scores of the individual road segments that comprisethe at least one candidate route; and sending the safety score for theat least one candidate route with the information related to the atleast one candidate route sent to the vehicle.
 15. A non-transitorycomputer-readable medium including executable instructions, which, whenexecuted by one or more processors, configure the one or more processorsto perform operations comprising: receiving, by the one or moreprocessors, from a vehicle computing device of a vehicle, locationinformation including a source location and a destination location;determining, by the one or more processors, a plurality of candidateroutes between the source location and the destination location;determining, by the one or more processors, based on the locationinformation, a plurality of landmarks along each candidate route betweenthe source location and the destination location; determining, by theone or more processors, one or more current conditions corresponding tothe plurality of landmarks along each candidate route; receiving, by theone or more processors, sensor configuration information for a pluralityof sensors onboard the vehicle; determining, by the one or moreprocessors, for individual landmarks of the plurality of landmarks alongeach candidate route, and based on the sensor configuration informationand the one or more current conditions, a probability of detection ofthe individual landmarks by multiple ones of the sensors of theplurality of sensors onboard the vehicle; determining, by the one ormore processors, respective scores for individual candidate routes ofthe plurality of candidate routes based on the probability of detectionof the individual landmarks of the plurality of landmarks along eachcandidate route by multiple ones of the sensors of the plurality ofsensors onboard the vehicle; sending, by the one or more processors, tothe vehicle computing device, and based at least on the respectivescores determined for the individual candidate routes, informationrelated to at least one candidate route that at least in part causes thevehicle computing device to select one of the at least one candidateroute as a selected route between the source location and thedestination location; receiving, by the one or more processors, theselected route from the vehicle computing device; determining, by theone or more processors, geometric associations for landmarks along theselected route; and sending, by the one or more processors, thegeometric associations for the landmarks to the vehicle computingdevice, the sending the geometric associations for the landmarks to thevehicle computing device causing at least in part the vehicle computingdevice to select one or more of the sensors of the plurality of sensorsonboard the vehicle and utilize the selected one or more sensors forlocating the landmarks along the selected route based at least on thegeometric associations, the vehicle computing device determining alocation of the vehicle for performing navigation based at least in parton locating the landmarks along the selected route via the selected oneor more sensors.
 16. The non-transitory computer-readable medium asrecited in claim 15, the operations further comprising: receiving theone or more current conditions over a network from one or more computingdevices, the one or more current conditions including one or more of:weather conditions, lighting conditions, a time of day, trafficconditions, construction taking place, or local events taking place. 17.The non-transitory computer-readable medium as recited in claim 15,wherein determining, based on the sensor configuration information andthe one or more current conditions, the probability of detection of theindividual landmarks by multiple ones of the sensors further comprises:determining a type of the sensors onboard the vehicle and a field ofview of the sensors onboard the vehicle, and determining a probabilitythat multiple different types of the sensors are able to detect theindividual landmark.
 18. The non-transitory computer-readable medium asrecited in claim 15, the operations further comprising: segmenting eachcandidate route of the plurality of candidate routes into a plurality ofroad segments; and determining the current conditions by determining thecurrent conditions for respective road segments of the plurality of roadsegments for each candidate route.
 19. The non-transitorycomputer-readable medium as recited in claim 15, wherein, followinglocating the landmarks along the selected route based at least in parton the geometric associations, the vehicle computing device determinesthe location of the vehicle based in part on associating the locatedlandmarks with corresponding landmarks on a navigation map.
 20. Thenon-transitory computer-readable medium as recited in claim 15, theoperations further comprising: receiving, from the vehicle, sensor dataindicating the landmarks detected during traversal of the selectedroute; and updating an indication of the probability of detection of oneor more landmarks in a landmark database based at least in part on thereceived sensor data.